resourceCriteria.addFilterInventoryStatus(null);
The Criteria API is a a powerful mechanism for creating ad-hoc queries against the domain entities and composites. It is the preferred mechanism for fetching data unless there is some overriding reason to use a more direct mechanism, such as a NamedQuery.
You'll find that many of the Remote API classes offer remote methods named findXxxByCriteria(Subject, XxxCriteria), or something very close. The XxxCriteria classes all extend Criteria and they all have some similarities. They all:
offer addFilter methods for filtering the returned data.
offer fetch methods for fetching optional (non-eagerly-fetched data).
offer sort methods for applying sorting.
implicitly support paging.
There are more design details here: Criteria Design.
Although powerful, there are subtle pitfalls if you're not careful. Here are several things to be aware of.
This is very important. This protects against an accidental fetch of a huge data-set. But it also surprises users when they don't see all the data they expect.
If you are positive the data-set will be manageable in a single fetch, you can call Criteria.clearPaging() to fetch an unlimited set.
If you need paging but don't like the defaults, you can call Criteria methods to override them.
If you want to easily support paging, see the CriteriaQuery wrapper class.
This class offers a simple way to iterate through a large data-set using the paging and sorting defined in your Criteria object. Note that with any
repeated searching of the database, changes to the underlying database tables can affect the results.
This is very important. For any String filter, unless documented otherwise, the supplied filter String will be treated as substring matching. This can lead to more results than expected. Be very careful when using name-filters and the like, when it's very possible you want exact match.
If you need exact match String filtering then call Criteria.setStrict(true).
Note that the strict match setting is applied to all String filters in the Criteria.
If you need case-sensitive searching, or you just want to be more efficient, then call Criteria.setCaseSensitive(true).
Criteria queries have great flexibility but remember that the ad-hoc nature of the querying means that the queries are assembled at call-time. Calling a fetchXxxByCriteria() method in a tight loop can be expensive. In certain situations it will be better to use existing lightweight convenience methods, like a getById(int id) method. Or, to add specific prepared statements/named queries, as needed.
As an aside, when working on SLSB code, remember that inter-EJB calling has transaction overhead. And repeating a lot of the same Authz checks can also slow things down considerably.
Several Criteria classes have default filters enabled. Make sure you look at the jdoc, or in some cases it's helpful to look at the class itself. For example, ResourceCriteria will, by default, limit your results to COMMITTED resources. To get back resources with any InventoryStatus you need to disable the filter:
resourceCriteria.addFilterInventoryStatus(null);
Since RHQ 4.6.
If you expect one and only one result object from your fetch, it's wise to wrap your call in a call to getSingleResult(). This will give you protection from unexpected result sets, analogous to what Query.getSingleResult() does in JPA.
ResourceCriteria c = new ResourceCriteria(); c.addFilterId(123); // This will thrown a RuntimeException if the call results in anything but one Resource Resource r = ResourceCriteria.getSingleResult(resourceManager.findResourcesByCriteria(c));